home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-07-26 | 3.3 KB | 84 lines | [TEXT/R*ch] |
-
- ADDITIONAL NOTES FOR AMIGA PORT
-
- These notes assume some familiarity with Amiga internals.
-
- WHY I PORTED TO THE AMIGA
-
- The sole reason why I made this port was as a first step in getting
- the Sather(*) language on the Amiga. A port of this language will
- be done as soon as the Sather 1.0 sources are made available to me.
- Given this motivation, the garbage collection (GC) port is rather
- minimal.
-
- (*) For information on Sather read the comp.lang.sather newsgroup.
-
- LIMITATIONS
-
- This port assumes that the startup code linked with target programs
- is that supplied with SAS/C versions 6.0 or later. This allows
- assumptions to be made about where to find the stack base pointer
- and data segments when programs are run from WorkBench, as opposed
- to running from the CLI. The compiler dependent code is all in the
- GC_get_stack_base() and GC_register_data_segments() functions, but
- may spread as I add Amiga specific features.
-
- Given that SAS/C was assumed, the port is set up to be built with
- "smake" using the "SMakefile". Compiler options in "SCoptions" can
- be set with "scopts" program. Both "smake" and "scopts" are part of
- the SAS/C commercial development system.
-
- In keeping with the porting philosophy outlined above, this port
- will not behave well with Amiga specific code. Especially not inter-
- process comms via messages, and setting up public structures like
- Intuition objects or anything else in the system lists. For the
- time being the use of this library is limited to single threaded
- ANSI/POSIX compliant or near-complient code. (ie. Stick to stdio
- for now). Given this limitation there is currently no mechanism for
- allocating "CHIP" or "PUBLIC" memory under the garbage collector.
- I'll add this after giving it considerable thought. The major
- problem is the entire physical address space may have to me scanned,
- since there is no telling who we may have passed memory to.
-
- If you allocate your own stack in client code, you will have to
- assign the pointer plus stack size to GC_stackbottom.
-
- The initial stack size of the target program can be compiled in by
- setting the __stack symbol (see SAS documentaion). It can be over-
- ridden from the CLI by running the AmigaDOS "stack" program, or from
- the WorkBench by setting the stack size in the tool types window.
-
- SAS/C COMPILER OPTIONS (SCoptions)
-
- You may wish to check the "CPU" code option is appropriate for your
- intended target system.
-
- Under no circumstances set the "StackExtend" code option in either
- compiling the library or *ANY* client code.
-
- All benign compiler warnings have been suppressed. These mainly
- involve lack of prototypes in the code, and dead assignments
- detected by the optimizer.
-
- THE GOOD NEWS
-
- The library as it stands is compatible with the GigaMem commercial
- virtual memory software, and probably similar PD software.
-
- The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
- compares favourably with an HP9000 with similar architecture (a 325
- with a 68030 I think).
-
- -----------------------------------------------------------------------
-
- The Amiga port has been brought to you by:
-
- Jesper Peterson.
-
- jep@mtiame.mtia.oz.au (preferred, but 1 week turnaround)
- jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
-
- At least one of these addresses should be around for a while, even
- though I don't work for either of the companies involved.
-
-